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Abstract 

On-line  help  facilities  are  essential  in  any  complex  system,  especially  for  introduc¬ 
tory  or  naive  users.  Previous  studies  have  highlighted  the  need  for  appropriate 
examples  along  with  the  description.  This  paper  describes  a  help/documentation 
facility  built  within  an  explanation  framework  that  plans  the  presentation  of  text 
and  examples  using  techniques  in  natural  language  generation.  The  paper  shows 
how  text  and  examples  can  influence  each  other  and  enumerates  some  of  the  other 
issues  that  arise  in  planning  such  presentations. 


h  INTRODUCTION 

Good  help  facilities  are  a  crucial  component  of  any  complex  system  (e.g.,  [1,2]),  and 
there  have  been  many  studies  on  generating  effective  online  help  (e.g  [3-6]).  Most 
attempts  at  providing  intelligent  help  facilities  have  focused  on  either  structured, 
hierarchical  menu  style  help,  as  in  the  VMS  online  help  system  [7],  or  on  hypertext 
style  browsing  capabilities  (e.g  [8, 9]).  However,  static,  online  help,  in  the  form 
of  canned  text  is  not  always  helpful:  in  one  study,  Houghton  found  that  in  most 
current  systems,  while  online  help  enhanced  the  performance  of  experienced 
users,  it  was  either  not  helpful,  or  sometimes  even  detrimental  to  inexperienced 
users  [10].  It  is  therefore  clear  that  online  help  systems  that  can  tailor  their 
descriptions  to  the  user  (particularly  the  inexperienced,  introductory  user),  would 
be  very  helpful. 

Tailoring  descriptions  to  the  user  often  involves  more  than  just  a  change  in  the 
terminology,  or  the  level  of  detail  presented  to  the  user  [11].  The  type  ofinformation 
presented  is  often  different  as  well:  for  instance,  syntactic  information  vs  °tructural 
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information  vs  functional  information.  One  of  the  differences  between  introductory 
material  and  non-introductory  material  is  the  importance  of  examples:  studi  os  by 
Beard  and  Calamars  [12],  and  Tuck  et.  al  [13]  found  that  the  component  help 
most  often  cited  as  necessary,  and  the  one  most  necessary  for  introductory  sers, 
was  the  presence  of  examples.  It  is  thus  clear  that  a  help  facility  desip  1  for 
introductory  users  must  be  able  to  include  examples  in  its  explanations. 

In  this  paper,  we  shall  describe  a  framework  for  an  explanation/heir  .acility 
that  can  generate  natural  language  descriptions  (of  objects  in  the  know!  ge  base) 
that  incorporate  examples  along  with  descriptive  text.  We  shall  brief  describe 
some  of  the  issues  that  arise,  and  using  a  simple  example  from  our  system  on  help 
in  LISP,  we  shall  describe  how  the  system  goes  about  planning  its  presentation. 

2.  ISSUES  IN  THE  USE  OF  EXAMPLES 

The  use  of  examples  can  contribute  a  great  deal  to  the  effectiveness  of  the  response. 
Indeed,  empirical  studies  have  found  that  examples  can  greatly  increase  user  com¬ 
prehension  (e.g.,  [14, 15]).  However,  studies  also  show  that  badly  integrated  text 
and  examples  can  actually  be  detrimental  compared  to  using  either  text  or  exam¬ 
ples  alone  (e.g.  [16]).  It  is  thus  clear  that  in  order  to  provide  useful  documentation 
automatically,  a  system  must  be  capable  of  providing  well-integrated  examples  to 
illustrate  its  points. 

There  are  many  issues  that  arise  in  gen¬ 
erating  complex  descriptions  which  include 
examples.  Although  some  tutorial  systems 
used  examples  in  explanations,  they  were  not 
considered  as  an  integral  part  of  the  complete 
explanation  and  were  inserted  in  the  expla¬ 
nations  without  any  representation  of  how 
the  examples  related  to  and  complemented 
the  accompanying  explanation.  Consider,  for 
instance,  a  help  description  generated  for  the 
term  ‘predicate-relation-form’  in  our  system. 
A  predicate-relation-form  is  a  non-terminal  in 
our  system’s  grammar,  and  its  parent  and 
child  relationships  are  shown  in  Fig.  1.  A  part  of  the  English  description  is  shown 
in  Fig.  2. 

Consider  the  description  in  Fig.  2:  the  system  first  describes  the  predicate- 
relation-form  by  describing  it  as  a  specialization  of  a  predicate-form  (which  returns 
a  boolean  value).  It  then  describes  the  syntax  of  a  predicate-relation-form. 
However,  the  description  does  not  include  the  facts  that: 

•  the  syntactic  detail  that  there  is  a  left  parenthesis  before  the  relation-name 
and  a  right  parenthesis  after  the  last  argument 

•  the  different  types  of  arguments  that  can  appear  after  the  relation 


> 


This  is  because  these  facts  are  communicated  through  the  examples  which  follow. 

I  The  parentheses  are  noted  in  the  system  as  ‘fixed  features’:  features  that  are 

constant  and  will  appear  in  the  same  location  in  every  example.  From  this,  the 
user  can  infer  that  those  features  are  necessary.  The  different  types  of  parameters 
that  can  appear  as  arguments  in  a  predicate-relation-form  are  (in  our  system: 
numbers,  symbols  and  instances)  also  illustrated  through  the  use  of  different 

I  parameters  in  the  examples.  A  natural  language  generator  should  be  able  to  take 

properties  of  both  the  descriptive  text  and  the  examples  into  account  and  generate 
a  coherent,  comprehensive  (yet  non-redundant)  explanation  with  examples.  Such 
descriptions  are  not  possible  to  generate  if  the  text  generator  and  the  example 
generator  do  not  interact  closely  in  planning  their  presentation. 

►  From  the  preceding  discussion, 
it  is  clear  that  the  inclusion  of 
examples  into  explanations  can 
cause  certain  portions  of  text  to 
be  elided.  However,  the  incorpora- 

►  tion  of  examples  into  descriptions 
can  also  cause  additional  text  to  be 
included  —  information  that  would 
not  originally  have  been  commu¬ 
nicated.  This  is  illustrated  by  the 

►  last  example  of  a  function-form  that 
is  presented  in  the  description. 

The  system  attempts  to  find  a  neg¬ 
ative  example  (an  example  that  is 
not  a  predicate-relation-form)  that 

►  is  as  similar  as  possible  to  one  of 
the  positive  examples  that  have  al¬ 
ready  been  presented.  In  this  case, 
the  system  attempts  to  generate  a 
negative  example  by  changing  the 

►  number  of  arguments  from  two  to 
one.  This  results  in  the  third  ex¬ 
ample  changing  from  a  predicate- 
relation-form  to  a  function-form.  The  system  attempts  to  point  this  out,  resulting 
in  additional  explanation. 

Thus,  as  even  this  brief  description  has  shown,  there  is  strong  interaction 
between  the  descriptive  text  and  the  accompanying  examples.  There  are  a  number 
of  other  issues  that  must  be  addressed  in  a  practical  generation  system,  such  as 
the  number  of  examples  to  be  presented,  the  order  of  presentation,  whether  the 

(  examples  should  be  presented  before,  after  or  within  the  description,  etc.  Due  to 

lack  of  space,  we  shall  not  discuss  these  issues  here.1  In  the  following  section, 


A  PREDICATE-RELATION-FORM  is  a 
predicate-form.  It  consists  of  a  relation  fol¬ 
lowed  by  some  parameters,  the  number  of 
which  is  equivalent  to  the  arity  of  the  rela¬ 
tion.  Examples  of  predicate-relation-form  are: 

(VERSION  LOAD-SOFTWARE  5.1) 
(STATUS  LED-1  'ON) 

(CONNECTED  COMPUTER-A  PRINTER-B) 

However,  the  following  is  not  a  predicate- 
relation-form,  because  the  number  of  argu¬ 
ments  is  not  equal  to  the  arity  of  the  relation. 
It  is  an  example  of  a  FUNCTION-FORM: 

(CONNECTED  COMPUTER-A) 

The  difference  between  a  FUNCTION-FORM 
and  a  predicate-relation-form  is  that  the  num¬ 
ber  of  arguments  in  a  function-form  are  one 
less  than  the  arity  of  the  relation,  and  . . . 

Figure  2:  Part  of  the  English  description 
of  predicate-relation-form. 


’See  (171  for  further  details. 


we  shall  describe  the  planning  framework  within  which  such  descriptions  are 
generated. 


3.  THE  SYSTEM 

Our  current  framework  implements  the  generation  of  examples  within  a  text- 
generation  system  that  explicitly  plans  text  to  achieve  a  communicative  or 
discourse)  goal.  Given  a  top  level  communicative  goal  —  such  as  (DESCRIBE 
OBJECT),  the  system  finds  plans  capable  of  achieving  this  goal.  Plans  typically 
post  further  sub-goals  to  be  satisfied,  and  planning  continues  until  primitive  speech 
acts  —  i.e.,  directly  realizable  in  English  --  are  achieved.  The  result  of  the  planning 
process  is  a  discourse  tree,  where  the  nodes  represent  goals  at  various  levels 
of  abstraction,  with  the  root  being  the  initial  goal,  and  the  leaves  representing 
primitive  realization  statements,  such  as  ( INFORM  .  .  . )  statements.  In  the 
discourse  tree,  the  discourse  goals  are  related  through  coherence  relations.  This 
tree  is  then  passed  to  a  grammar  interface  which  converts  it  into  a  set  of  inputs 
suitable  for  input  to  a  natural  language  generation  system  called  PENMAN  [18]). 
A  fragment  of  the  text  plan  gen¬ 
erated  by  the  system  for  the 
description  in  Fig.  2  is  shown 
in  Fig.  3.  The  skeleton  shows 
the  structure  of  the  plan,  along 
with  the  discourse  goals  posted 
by  the  system.  The  two  top- 
level  goals  posted  by  the  ini¬ 
tial  goal  are  (DESCRIBE  (SYN¬ 
TAX  PRED-REL-FORM))  and 
(EXEMPLIFY-FEATURES  (SYN¬ 
TAX  PRED-REL-FORM)).  The 
first  goal,  to  describe  the  fea¬ 
tures  ultimately  results  in  the 
first  part  of  the  description, 
which  states  that  a  predicate- 
relation-form  consistes  of  a 
relation-name  followed  by  some 
arguments.  The  second  goal,  to 
exemplify  the  features  of  a  predicate-relation-form  results  in  the  generation  of 
the  actual  examples,  along  with  the  associated  background  text  (“Examples  of 
predicate-relation-form  are  . . .  ”). 

Thus,  examples  are  generated  by  explicitly  posting  a  goal  within  the  text 
planning  system:  i.e.,  some  of  the  plan  operators  used  in  the  system  include  the 
generation  of  examples  as  one  of  their  steps,  when  applicable.  This  ensures  that 
the  examples  embody  specific  information  that  either  illustrates  or  complements 
the  information  in  the  accompanying  textual  description.  Additional  sources  of 
knowledge  such  as  the  user  model,  text  type,  dialogue  context,  etc,  can  be  added 


DESCRIBE 

PREDICATE 

RELATION- 

FORM 


DESC  RIB  E-ATTRIBUTE 

(SYNTAX  PRED-REL-FORM) 


Figure  3:  Plan  fragment  for  the  predicate- 
relation-form. 


to  the  system  by  incorporating  additional  constraints  in  the  plan  operators. 

Using  this  framework,  we  have  generated  descriptions  of  constructs  in  the  pro¬ 
gramming  language  LISP  [19]  and  documentation  for  the  grammar  in  our  own  plan 
language  [20]  for  the  EES  expert  system  framework  [21].  The  generation  of  these 
descriptions  highlight  some  of  the  issues  that  must  be  addressed  by  any  interface 
that  must  integrate  natural  language  and  examples  together.  Some  of  these 
issues  are  also  applicable  to  the  generation  of  multi-media  explanations,  where 
the  constraints  imposed  by  the  non-textual  component  upon  the  text  planner  must 
be  taken  into  account. 

4.  CONCLUSIONS 

Examples  are  essential  in  explanations,  especially  for  naive  users.  It  is  therefore 
important  that  on-line  help  systems  designed  for  non-expert  users  be  able  to 
present  effective  and  appropriate  examples  to  the  user.  As  systems  evolve  over 
time,  it  is  essential  that  the  documentation/help  fa.nlity  be  updated  to  reflect 
the  changes.  A  system  that  generates  documentation  from  the  underlying  code 
would  help  alleviate  the  ‘maintenance  of  documentation’  problem.  However,  such 
a  system  would  then  need  to  be  able  to  present  examples  and  text  in  a  coherent 
and  integrated  manner.  In  this  paper,  we  have  presented  some  of  the  issues  that 
arise  in  the  planning  of  such  presentations.  The  issues  we  have  described  are  not 
specific  to  a  particular  framework.  Our  implementation  demonstrates  that  it  is  not 
just  desirable,  but  also  feasible  to  build  such  on-line  help  systems  by  making  use 
of  advances  in  natural  language  generation  and  knowledge  based  systems.  This 
work  is  important  in  other  related  application  areas  such  as  intelligent  tutoring 
systems,  expert  system  explanation  and  user  interfaces. 
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